Fix missing grant_type in Authress token exchange; stop guessing on exchange failures - #11

Summary

• The token exchange body (POST /authentication/{id}/tokens) never sent grant_type or client_id, and used camelCase field names (codeVerifier, redirectUri). Cross-checked against @authress/login's own minified source: this is the one endpoint in the SDK that's OAuth-shaped and expects grant_type=authorization_code, client_id, code_verifier, redirect_uri (snake_case). Authress was rejecting the exchange outright — this is the source of the "grant type" error on login.
• The exchange's error handling assumed any sub-500 status meant "code already redeemed" and silently treated it as a successful login, without checking whether a session actually existed and without logging what the failure actually was. Now every exchange failure is logged with its real status/body at ERROR level, and is only treated as harmless once a session cookie is verifiably present (an objective check, not a guess from the status code) — otherwise it surfaces as a real error via authError instead of silently bouncing the user back to the login screen.

Test plan

• Manual sign-in against a live Authress backend to confirm the token exchange now succeeds
• Confirm a genuinely failed exchange now shows a real error on LoginScreen instead of silently resetting to "Continue"
• Not build-verified in this session — the Gradle wrapper jar is not present in this environment (pre-existing, unrelated to this change)

Generated by Claude Code